SBUS 32 Channel - #536

THX!
as much as I can see it also should work with AP, in the sense that AP would ignore it and not do nonsense

since these two functions are so extremely similar, I wonder if it wouldn't be worthwhile to make it one, with a flag to set which one it shoudl pack?

in addition, it should be checked if the 0x2F frame could be send a different rate than the 0x0F frame, or if they always must come together

as much as I can see it also should work with AP, in the sense that AP would ignore it and not do nonsense

For SBUS, AP uses 2 ms idle and INAV uses 3 ms idle to detect end of frame, so now send the second message 3.5 ms after the first completes

since these two functions are so extremely similar, I wonder if it wouldn't be worthwhile to make it one, with a flag to set which one it shoudl pack?

Done.

in addition, it should be checked if the 0x2F frame could be send a different rate than the 0x0F frame, or if they always must come together

Now send at 5 Hz, same as CRSF - so now have do_rc_channels32 function.

hm, this comes out more "ugly" now that I thought ... I think this needs more thinking

at 100k baud, 25 bytes are 2.5 ms. Thus, one cylce is at minimum 2.5ms + 3.5ms + 2.5ms + 3.5ms = 13 ms ... this is substantially more than possible for e.g. 111 Hz (= 9ms). I.e., one needs to aditionally throttle like we do in others down to 50 Hz, but one would do that only if 32 channels. Hmmm ... not super nice. Furthermore, given it's more complicated than it initially loks I guess this needs proper testing really.

the 6500 probably should be 3500, right

at 100k baud, 25 bytes are 2.5 ms.

SBUS is 8E2, so 12 bits per byte, so 25 bytes = 3 ms

this is substantially more than possible for e.g. 111 Hz (= 9ms)

This is correct but not really an issue IMO - ArduPilot will loose 5 low frames and the INAV timeout isn't enforced after a high frame, so it accepts the next low frame.

Regardless, it seems INAV needs a code change (iNavFlight/inav#12109), so I suppose we can park this.

SBUS is 8E2, so 12 bits per byte, so 25 bytes = 3 ms

so even worse :)

This is correct but not really an issue IMO - ArduPilot will loose 5 low frames and the INAV timeout isn't enforced after a high frame, so it accepts the next low frame.

well, frankly, I'm not for such dirty hacks at all. It also seems that the 0x2F frame is not really a "standard" ... I wonder if it is a BF/INAV invention ...

I convert this into a WIP
don't want to loose it but looks to me needs more investigation. I personally find it important that it cooperates well with ArduPilot. Now that 32 channels appear to come to AP, we possibly can extend their sbus implementation alongside.

wonder if it is a BF/INAV invention ...

Well not this time :) It's how Futaba does 26 Channel.

One idea would be to just switch to 200K Baud (SBUS_FAST) which both AP & INAV support. This could either be done when 32 channels are detected or as a new entry in the SBUS options.

Will revisit when AP / INAV are further along.